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(54) Establishing connections between remote devices with a hypertext transfer protocol 



(57) A connection between remotely controllable 
devices (1; 1 A, 1 B, 1C) is established by controlling said 
remotely controllable devices (1 ; 1 A, 1 B, 1 C) independ- 
ently by use of a hypertext transfer protocol. Such a 
remotely controllable device (1; 1A, 1B, 1C) comprises 
a control interface (3) using a hypertext transfer protocol 
to establish said connection. A control device (2) for per- 
forming such a remote control comprises a first inter- 
face (2a) to control said controllable devices (1 ; 1 A, 1 B, 
1C) remotely using a hypertext transfer protocol to 
establish said connection between at least two of said 
remotely controllable devices (1; 1A, 1B, 1C). A control 
device (2) according to the present invention is charac- 
terized by a second interface (2b) to control said control 
device (2) using a hypertext transfer protocol. With the 
invention directly controllable connections between 
remotely controllable devices can be established with a 
hypertext transfer protocol. 
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Description 

[0001 ] The present invention relates to a method for establishing a connection between remotely controllable devices, 
in particular a guaranteed bandwidth connection, and also to remotely controllable devices and a control device 
adapted therefore. 

[0002] In the following the remotely controllable devices will be identified just as remote devices. 
[0003] A method for controlling a remote device with HTTP is known from the internet. Certain internet sites demon- 
strate how to control an audio-video-device (AV-device), such as an audio tuner or a television receiver to switch to dif- 
ferent channels so as to broadcast different selectable information to and via the Internet. An example of such a system 
is shown in Figure 14. Here, it is shown how to control a radio with HTTP. A radio transmitter 100 as source device 
inputs an analog signal with multiple services to a target device, here a server 101 offering a universal resource locator, 
e g. rrttp//www.chilton.com/scripts/radio/R8-receiver. The server 101 includes a micro-controller and HTTP server 103 
offering the possibility to select one of the multiple services received from the radio transmitter 1 00 via the internet and 
to output it to the internet. In this case HTTP is used as transfer protocol. The micro-controller and HTTP server 103 
offers a graphical user interface to any internet user selecting the universal resource locator of the server 101 . An inter- 
net user needs a controller 102, like a Web Browser to establish an asynchronous connection to the server 101. This 
asynchronous point-to-point connection is established for audio data and for the HTTP control protocol. 
[0004] It is also known from the internet to establish a connection between two remote devices, i. e. between two 
HTTP servers. An example of such a connection is shown in Figure 15. An internet user can connect to a target device 
105 that is a HTTP server with a search engine function. The connection to the target device 105 is an asynchronous 
connection for the control of the target device 105 and the data retrieval from the target device to the controller 102 (i. 
e Web Browser) of the internet user. If the HTTP server 105 cannot provide the requested data itself. There is the pos- 
sibility that this target device can establish a second asynchronous connection to another HTTP server 1 04 also serving 
as a search engine. Such a connection between these two remote servers 1 04 and 1 05 Is not directly controlled by the 
25 internet user, but is self -established by the target device selected by the internet user. In the shown example, the inter- 
net user connects with his Web Browser 102 to the target device Yahoo with the universal resource locator 
"www.Yahoo.com" and the target device Yahoo establish an asynchronous connection to a source device Altavista with 
the universal resource locator "www.Altavista.digital.com". 

[0005] In both shown examples not only the control data, but also audio data or retrieval data is transported on a con- 
ventional TCP/IP (Transmission Control Protocol/Internet Protocol) connection which does not offer guaranteed band- 
width Therefore, after the control of the target device using e. g. HTTP also the requested information is transmitted to 
the internet user via his/her Web Browser 102 using HTTP. This implies sometimes long waiting times, since an HTTP 
connection can not reserve guaranteed bandwidth. 

[0006] On the other hand, network environments are known that require interoperability between audio/video sources 
35 and target devices having transport mechanisms e. g. defined in IEEE 1394 that is used to enable communication 
between attached devices with guaranteed bandwidth. Such a network environment is shown in Figure 13. IEEE 1394 
specifies "isochronous" channels which offer guaranteed bandwidth between attached source and target devices. Addi- 
tionally there are "asynchronous" channels which offer point-to-point connections for system specific control protocols. 
Here, various system specific protocols are specified e. g. for digital VCRs, DVB tuners, DAB tuners, etc., to enable con- 
40 trol of the corresponding devices of various types. In Figure 1 3 two of such remote devices 1 are shown. One Is a tuner 
device type 1 A and the other is a storage media device type 1 B. Both devices 1 have a logical Interface 4 connected to 
the isochronous channels of the IEEE 1394 network. Both devices 1 comprise a micro-processor 9 used to control 
these devices 1 . Both devices 1 also have a logical interface 6 connected to a controller 2 via an asynchronous channel 
of the IEEE 1394 network. Such a multifunctional controller 2, i. e. a system capable of controlling all attached remote 
45 devices 1 , needs to support all system specific protocols and has therefore a relatively complicated structure. Further- 
more, adding an additional device type requires in general a corresponding upgrade of the controller 2, since every 
remote device 1 of a different type or make needs a system specific control protocol to be sent via the asynchronous 
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channel. 

[0007] As mentioned, each remote device type connected to an IEEE 1 394 network system requires a specific control 
protocol. Consequently, to enable a user to control said type of devices the implementation of controller 2 becomes 
complicated, since all relevant protocols have to be known. It is difficult that controllers are feasible for controlling all 
systems, since so called dedicated controllers are used that are intended for one system type. A further difficulty lies in 
the fact that the respective system specific protocol is relatively rigid as it is Intended to enable control of low level 
device functions. Consequently, in case of upgrading a remote device 1 in the IEEE 1394 network, often an associated 
upgrade of the controller 2 is also necessary, since the existing protocol needs to be extended. Also, adding a new 
remote device type to the IEEE 1394 network will be a problem, since the controller 2 has either to support a new sys- 
tem specific protocol or the new remote device 1 has to support one of the system specific protocols already known by 
the controller 2. Furthermore, as the system specific protocols are relatively rigid, a controller manufacturer can easily 
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design the user interface in such a way that it conceals any look-and-feel of the controlled remote device 1 . This could 

discourage certain equipment manufacturers from supporting IEEE 1394 networks. The latter may also lead to 

increased support for non-compatible network protocols which would result in even more interoperability problems. 

[0008] A device control with HTTP as it Is now available in internet solves the problems mentioned above. But in this 
5 case no directly controllable connection in-between two remote devices 1 is established and any requested data, e. g. 

audio and video data, is transported over a connection that does not guarantee adequate bandwidth so that in case of 

congested network connections a discontinous data flow is the result, such as a discontinous audio/video playback. 

Also most Web authors miss the chance to educate the users by displaying a graph of the data flow. 

[0009] Therefore, it is the object of the present invention to offer a simple method and a control device for establishing 
10 a connection between remote devices, e. g. network devices. 

[0010] The inventive method to establish a connection between remote devices is characterized by controlling said 

remote devices independently by using a hypertext transfer protocol. 

[0011] Preferrably the remote devices are controlled via a control device, wherein said control device controls said 
remote devices using a hypertext transfer protocol. Said control device can either be remotely controlled also using a 

is hypertext transfer protocol or directly controlled via a user interface included in the control device. 

[001 2] Further preferrably said connection between remote devices is a guaranteed bandwith connection. 
[001 3] According to the invention, instead of using several system specific protocols, a hypertext transfer protocol, i.e. 
HTTP, is used to orchestrate interaction between multiple remote devices. Each device operates like an internet server 
and can present a menu of options that correspond with a certain control function. The set up of a controller becomes 

20 a lot easier, since only one control protocol has to be supported by the controller. In case of upgrading the network sys- 
tem by adding an additional remote device type, it is not necessary to include a new control protocol into the controller. 
This can preferably be done by downloading a user interface from each of said remote devices that should be controlled 
by the controller into the controller and offering said user interfaces to a user who wants to control said remote devices. 
[0014] Further preferred embodiments of the inventive method defined in claim 1 are defined in dependent claims 2 

25 to 12. 

[001 5] A remote device according to the present invention that can establish a connection to other remote devices is 
characterized by a control interface via which said remote device is controllable using a hypertext transfer protocol to 
establish said connection. 

[0016] Preferrably said control interface stores a user interface that can be a graphical user interface. With such a 
30 user interface the remote device according to the present invention effectively acts like a HTTP server. In this case the 
user interface that is stored in the control interface is downloaded from said remote device to a control device when the 
remote device is accessed by a user via a control device. Then, all functionalities of the remote device are accessable 
via the controller used by the user. 

[0017] Further preferred embodiments of a remote device according to the invention as defined in independent claim 

35 13 are specified in dependent claims 14 to 22. 

[0018] As can be taken from the above explanation, any Web Browser that is able to connect to more than one or 
more HTTP server(s) can serve as a controller to control the devices according to the present invention. However, when 
considering home network environments like the IEEE 1394 network system, it is desirable that every device can be 
directly accessed by a controller when the user wants to control the home network from outside. Therefore, a control 

40 device according to the present invention with a first interface to control remote devices using a hypertext transfer pro- 
tocol is characterized by a second interface to control said control device using a hypertext transfer protocol to establish 
a connection between at least two of said remote devices. 

[001 9] Such a control device according to the present invention is defined in independent claim 23. Dependent claims 
24 to 28 specify preferred embodiments thereof. 

45 [0020] Networks built up with remote devices according to the present invention and a control device according to the 
present invention that work according to the inventive method improve the user-friendliness by offering more interesting 
user interfaces, since each device can present its own unique user interface e. g. in an HTML frame, and enables an 
easy upgrade of the network system, since there has to be no special controller for each remote device type (that is 
working like a server). Furthermore, in a preferred embodiment audio and video data are only transported over a con- 

50 nection that guarantees adequate bandwidth, whereas the control commands can be transmitted either over a guaran- 
teed bandwidth connection or over an asynchronous connection. 

[0021] Other objects, advantages and features of the present invention will be better understood from the following 
detailed description of preferred embodiments thereof taken in conjunction with the accompanying drawings, wherein: 

55 Figure 1 shows an IEEE 1394 network configuration according to the present invention; 

Figure 2 shows an IP address assignment in a system according to figure 1 ; 

Figure 3 shows an example of the initialization procedure of the home net DNS server; 

Figure 4 shows an example of the DNS server reply to an external request; 
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Figure 5 shows an example of a HTTP server initialization in a system according to figure 1 ; 

Figure 6 shows an example how the system according to the invention reacts on a first user command; 

Figure 7 shows an automatic conversion to a newly proposed URL convention with "server redirect" response 
according to the invention; 
5 Figure 8 shows an example of the first menu from the server according to the present invention; 

Figure 9 shows a process of changing the isochronous source for a storage device according to the present inven- 
tion; 

Figure 1 0 shows an example of the new storage device state after the process shown in Figure 9, and the switching 
to another remote device according to a user action; 
w Figure 1 1 shows the logical connections of an extended network; 

Figure 12 shows the physical connections of the network environment according to the invention; 
Figure 1 3 shows a conventional IEEE 1 394 network configuration; 

Figure 14 shows the controlling of a radio with HTTP In the internet according to the prior art, and 
Figure 1 5 shows the conventional automatic connection between two remote devices in the internet. 

15 

[0022] Figure 1 shows an IEEE 1 394 network configuration according to the present invention, Three remote devices 
1A, 1B, 1C of different types are respectively connected to isochronous connections for the broadcast of data, e. g. 
audio/video data that offer guaranteed bandwidth via a data interface 4 included in each of said remote devices 1 A, 1 B, 
1 C. Such isochronous connections could a g. be established via an IEEE 1 394 bus system. It is also possible that other 

20 than garanteed bandwith connections, e.g. asynchronous connections, are used. On the other hand, the remote 
devices 1 A, 1 B, 1 C respectively comprise a control interface, i.e. a hypertext transfer protocol server 3 via which each 
of said remote devices 1 A, 1B, 1C establishes an asynchronous connection to a controller 2. Said hypertext transfer 
protocol server 3 comprises at least a microcontroller and a memory. Such an asynchronous connection is a point-to- 
point connection for device control protocols. In the case shown, according to the present invention a hypertext transfer 

25 protocol, e. g. HTTP, is used as device control protocol. The HTTP server 3 that includes microcontroller and memory 
in each of said remote devices serves as gateway for controlling the respective remote device 1 A, IB, 1C, e. g. for con- 
trolling the respective logical interface 4 and the respective processing of the remote device 1 A, 1B, 1C. 
[0023] in figure 1 , a tuner device 1 A as source device is shown that comprises a switch 6 for selecting amongst one 
of several services of an input signal with multiple services. The HTTP server 3 of the tuner device 1 A controls the 

30 processing within the tuner device 1 A and the data interface 4 of the tuner device 1 A according to a preset algorithm, 
the switch 6 can be controlled by a user via the controller 2 and the HTTP server 3 of the tuner device 1 A. Furthermore, 
a storage medium device 1B is shown, wherein the storage medium 7 itself and the processing within the storage 
medium device 1 B is controlled by the HTTP server 3 according to a present algorithm and the selection to begin and 
end the storage or playback of the data of a certain connected isochronous connection is performed by a user via the 

35 controller 2 and the HTTP server 3 of the storage medium device 1 B. 

[0024] In the shown example also a remote display device 1 C is connected to the isochronous connections 5 and to 
the controller 2. This remote display device 1 C is connected to the controller 2 via an asynchronous connection. It can 
be controlled with the same protocol, i. e. HTTP, and with the same controller 2 as the remote storage media device 1 B, 
but the data of the selected isochronous connection is displayed instead of being stored. As it is indicated in figure 1 by 

40 broken lines, such a display device can be integrated with the controller 2. In this case, the "connection" within such a 
device needs not necessarily to be an asynchronous connection and the display needs not necessarily to be controlled 
using a hypertext transfer protocol. 

[0025] The controller 2 can be accessed by a user to control each of the remote devices 1A, "IB, 1C connected 
thereto. Apart from the selection which isochronous channel is to be used by a device to broadcast data via a guaran- 

45 teed bandwidth connection, which is selected by the system itself in dependence of currently available capacities, the 
user can fully control each of the remote devices 1 A, 1B, 1C. In the shown example the user can select which of the 
multiple services input into the remote tuner device 1 A, should be processed and broadcasted to an isochronous con- 
nection by controlling the switch 6. The remote storage medium device 1B is controlled by the user to select one of the 
connected isochronous connections, the incoming data of which should be processed and recorded on the storage 

so medium 7. 

[0026] According to the invention, there is no need for a different controller 2 for each of said remote devices or a 
controller 2 that is specially adapted to all of the remote devices connected to the system, since the remote devices 1 A, 
1B, 1C are respectively and independently controlled using the same protocol, i. e. a hypertext transfer protocol, e. g. 
HTTP. The controller can be a relatively low cost device which only supports asynchronous connections. By using HTTP 
55 instead of control protocols specially designed for each of the remote devices 1 , the controller effectively functions as a 
Web Browser. To enable the use of existing Browsers, the same protocols are used as are now used in the internet, i. 
e. IP, TCP and HTTP. 

[0027] In Figure 1 the isochronous and asynchronous connections are displayed separately, but in real systems both 



4 



fl 



EP 0 940 959 A1 



types of connections are supported in the same cable, as it is the case in the IEEE 1394 system. In IEEE 1394 a 
method is specified to support IP on top of IEEE 1394 connections, consequently it can also support TCP and HTTP 
connections. It is also thinkable that a naming system such as DNS (Domain Name System) enables the assignment 
of domain-names to remote devices and that other protocols will be implemented to improve the plug and play behavior, 
5 e. g. for automatic assignment of IP addresses, net masks or DNS name servers. DHCP (Dynamic Host Configuration 
Protocol) or a similar protocol can serve to do this. 

[0028] Figure 2 shows an example of conventional IP address assignment to the remote devices 1 A, 1 B and controller 
interfaces 2a and 2b to support the invention. 

[0029] The IEEE 1394 bus system is currently being used to connect consumer audio/video devices. However, 
w according to the present invention, it is possible to: 

(J) Connect such remote devices to internet servers, e. g. for software upgrades. 

© Besides using the controller 2 to control and view conventional 1394 services, the user can use the same con- 
troller 2 to select and access internet services. 
15 @ Connections to the internet can also be necessary for other reasons, e. g. travelling customers may require 
access to their remote home network devices through the internet. 

[0030] Parts of the following initialization procedure have been designed to accommodate such features. In the fol- 
lowing example, it is assumed that the controller 2 is a PC or a PC-like device that could function as a gateway to the 
20 internet as shown in Figure 1 2. The connection to the internet can be supported, e. g. by a telephone modem or a cable 
modem. The following sections describe each step of the boot procedure after a conventional network initialization has 
been described. 

[0031] Figure 13 shows the conventional IEEE 1394 network initialization. Two remote devices, e. g. a tuner device 
1 A and a storage media device 1 B, are connected to isochronous connections 5 of the IEEE 1 394 network via a respec- 
ts tive logical internal data interface 4. Furtheron, they are respectively connected to a controller 2 via a logical interface 
and an asynchronous connection of the IEEE 1394 network. The controller 2 needs to be adapted to the tuner device 
1 A and the storage media device 1 B, since each remote device type has a different set of control commands. The con- 
troller 2 has access to a remote display and input device or such a device is integrated within the controller 2 as display 
and input device 8 as described above. 
30 [0032] The conventional IEEE 1394 network initialization is performed after power-on or ( reinitialization. Here, all 
devices attached to the network will attempt to boot to their preferred state. One of the steps to accomplish this is e. g. 
the identification of certain master devices such as an isochronous resource manager and the allocation of node_ids to 
enable the setting up of IEEE 1394 asynchronous connections. This procedure is described in the IEEE 1394 specifi- 
cation. After providing this transport layer, the devices will contact other devices to obtain more information about their 
35 capabilities and to determine the network topology etc. Such information will be stored in each device to support basic 
communications. Furthermore, additional information may be stored locally to enable advertising capabilities to the user 
at a later stage. 

[0033] According to the present invention, the first step of the boot procedure is the conventional network initialization 
as described above for IEEE 1394. After such an IEEE 1394 transport layer has been established, the IP (Internet Pro- 

40 tocol) network initialization can be started. To support plug and play as much as possible, the automatic assignment of 
parameters, such as IP addresses and IP netmasks, is required. Devices, which need access through a router, e. g. to 
make connections to remote internet sites, will also need to know the default router IP address. For automatic assign- 
ment of such parameters in addition to the basic IP protocol family, it is useful to use a protocol such as DHCP. In simple 
IEEE 1394 networks, it is possible to avoid using a protocol like DHCP, if some kind of standardized IP address assign- 

45 merit convention is available. E. g. IP addresses can be derived from the IEEE 1394 worldwide unique ID. This makes 
it possible to guarantee locally unique IP addresses. Also, the name server and router can adopt standardized IP 
addresses to enable fixed name server and default router entries in each IP device. Devices that have multiple roles can 
assign multiple IP addresses to their interfaces if necessary. 

[0034] In the example shown in figure 2, the remote tuner device 1 A has the following addresses assigned to its HTTP 
so server 3: 



Default router: 
DNS server: 
Net mask: 
55 IP address: 



192.168.0.1 
192.168.0.1 
255.255.255.0 
192.168.0.2 



[0035] Whereas the remote storage media device 1 B, has the following addresses assigned to its HTTP server 3: 
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DNS server: 
Net mask: 
IP address: 



Default router: 



192.168.0.1 
192.168.0.1 



255.255.255.0 
192.168.0.3, 



5 



and the controller 2 that also serves as a gateway to the internet and has access to a display and input device 8 com- 
prises two interfaces, an internal interface 2a for the DNS server and home net DHCP server with the following 
addresses: 

w IP address: 192.168.0.1 
Net mask: 255.255.255.0 
DNS server: 192.168.0.1, 

and an external interface 2b for the communication with the internet having the following addresses: 



Default router: 192.109.206.1 

20 [0036] These addresses could either be fixed addresses according to a future standard to make the system more sim- 
ple, but they can also be assigned during the IP network initialization e. g. with DHCP. 

[0037] For the external connection to the internet a lower layer, such as PPP (Point to Point Protocol) or a telephone 
line, will be required to support the IP traffic. This part of the network initialization process is a standard and will not be 
described here. 

25 [0038] In case a DHCP protocol is used it will depend on the requirements which device will function as a DHCP 
server. If the IP stack is only required to support HTTP control with web browsers, the IP stack is necessary if at least 
one HTTP server and at least one HTTP client are connected to the network. It is expected that in typical home net- 
works the total number of source and target devices will be larger than the total number of controllers. 
[0039] Assuming that the network has one controller 2 that is acting as an HTTP client, and several remote source 

30 and target devices 1 ; 1 A, 1 B each acting as an HTTP server, the controller 2 would be involved in all HTTP sessions for 
all remote devices 1 . Therefore, to limit the dependency on other remote devices, it would be appropriate to locate the 
DHCP server on the controller 2. 

[0040] However, if IP is also required for other purposes, e. g. as a transport means to download new control software 
from internet to non-controller devices 1 ; 1 A, 1 B and if the controller 2 is not the gateway to the internet, It may be pre- 

35 ferrable to support the DHCP server on a non-controller device. 

[0041 ] To support IP traffic with the internet, appropriate routing and address values are required in the home network. 
Considering that a large number of home networks with an even larger number of devices is expected, It would not be 
feasible to use registered internet addresses within the home network, as these are already a scarce resource. There- 
fore, for this purpose a special range of "private" addresses should be used (e. g. 192.168.0.0 to 192.168.255.255) 

40 which have been provided by the IETF (Internet Engineering Task Force). These addresses do not exist in the internet 
and consequently they can be used and re-used by private networks. In figure 2 a network address in this range, i. e. 
192.168.0.0, is used by the DHCP server. In addition to assigning locally unique addresses, the DHCP server also 
assigns a 3 byte netmask, IP addresses of the default router, i. e. 192.168.0.1, and name server, i. e. 192.168.0.1, to 
each home net device 1 ; 1 A, 1 B. 

45 [0042] As the controller 2 functions as a gateway to the internet, it needs a special IP configuration. The controller 
comprises an additional IP interface 2b with an internet registered address, which enables the device to communicate 
with external internet sites, in the shown case, the IP address 192.109.206.33. For this purpose, the controller 2 needs 
a different default router address that should refer to a router in the internet. The value of such parameters depends on 
which ISP (Internet Service Provider) gateway is used. Just as the DHCP server of the home network assigns such 

so parameters to devices 1 A, 1 B inside the home network, also the ISP could use a DHCP server to assign appropriate IP 
parameters to the home networks external interface 2b. In figure 2, the ISP's DHCP server assigned the address 
192.109.206.33 to the external interface 2b of the controller 2. Furthermore, the ISP instructed the home net gateway 
to use 193.109.206.1 as its default router. 

[0043] After the IP configuration, the home network gateway will translate any internal IP address to the external IP 
55 address for outgoing IP packets and vice versa for incoming packets. 

[0044] As alternative to identify devices 1 ; 1 A, 1 B and the controller 2 only with addresses, the association of names 
with devices 1 ; 1A, 1B or the controller 2 might be feasible. As in internet, there are four reasons why the addressing 
with names is desireable in addition to the addressing with IP addresses: 



15 



IP address: 
Net mask: 



192.109.206.33 
255.255.255.0 
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To improve the user friendliness each device should also have an appropriate name associated with it. This enables 
users to address devices with names that could be typed or even spoken instead of numbers. 
IP addresses should be concealed from the Web Browser because they may change due to dynamic assignment 
of such adresses. 

5 * Furthermore, even if such addresses were fixed, H a nomadic controller would bookmark such IP addresses, it 
would not be able to use this bookmark from an external network, because the internet does not support such pri- 
vate numbers. In other words, the IP addresses of the local home network are only valid within the home network 
environment. A nomadic controller in this case is a portable device which can be moved from a home network to a 
remote Internet connection or vice versa. To support the IP addresses of the local home network, the portable 

w device would need to know the home networks external IP address or addresses. Also this address may be 
assigned dynamical by the internet service provider and therefore it should not be stored as a bookmark. 
In systems where multiple devices offering the same kind of service are included, it is sometimes desireable to use 
the same server name but to map this name to different IP addresses. The main intent of this approach is usually 
to distribute the load of multiple clients on more than one server. 

75 

[0045] To cope with these situations, the home net uses a DNS, i. e. a Domain Name System, where "name servers" 
are used to translate names to the appropriate (P address. Systems that wish to contact a device with its name first con- 
tact a name server. The latter replies with the appropriate IP address, which enables further communication. 
[0046] A home network according to the invention using a DNS is shown in Figure 3. The difference in-between f ig- 
20 ures 3 and 2 lies not only in the controller 2 that now additionally serves as DNS server in this case, but also the respec- 
tive microcontrollers 3 of the remote devices have an additional entry, namely a device description, e. g. a 1394 device 
description, indicating the kind of the device, e. g. tuner, storage, controller, etc. . [Note: Figure 2 shows the state after 
IP initialization. The next step is DNS initialization, as shown in figure 3.] 

[0047] Additionally to the content of the controller 2 shown in Figure 2, the controller 2 shown in Figure 3 comprises 
25 of a 

DNS server responsible for domain: no29.bahnstrasse.bonn.de, 
and a DNS database with the following content: 
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subdomain 


answer for internal 
devices 


answer for external 
devices 


tuner 

storage 

controller 


192.168.0.2 
192.160.0.3 
192.160.0.1 


192.109.206.33 
192.109.206.33 
192.109.206.33 



wherein also additional devices would have an entry with their names assigned to two addresses. 
40 [0048] If a system in the internet would need to access the remote home network, it would need to communicate with 
the internet service provider connected to the remote home network. Assuming this home network is located e. g. in 
Bonn, the internet service provider could for example assign a name with reflects the location of the home network, 
such as: "no29.bahnstrasse.bonn.de" as in the shown example. 

[0049] With the domain name (no29...) from the internet service provider, the home net server within the controller 2 
45 can assign unique names to each of its home net devices 1 ; 1 A, 1 B, these names are fully qualified domain names. 
Assuming that the IEEE 1 394 specification already has a convention for device names, the home net DNS server could 
extract such a device name as specified by the IEEE 1394 standard and then prepend this name to the home net 
domain. For example, rf a device was called "storage" in the IEEE 1394 home network, the DNS server could use this 
as a subdomain identifier for the respective device, i. e. B storage.no29.bahnstrasse.bonn.de". Alternatively to such an 
so automatic assignment of the fully qualified domain name, a manual assignment can be performed by an operator of the 
remote home network. 

[0050] With all this data, i. e. the device description as specified by the IEEE 1 394 network, the IP addresses assigned 
by the home net DHCP server, the IP address for the gateway's external interface assigned by the internet service pro- 
vider and the home net domain assigned by the internet service provider, the home net DNS server inside the controller 
55 2 can build a database as shown above and in figure 3. During such an initialization procedure, the controller 2 can dis- 
play a message, such as "Please wait a moment..." on the display and input device 8 connected thereto. 
[0051] The DNS server has to prepare two possible IP addresses for each device connected to the network. The 
entries depicted in the second column, i. e. private IP addresses, are used if an internal device requests a name trans- 
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lation, The value in the third column, i. e. internet IP address, is used when replying to requests from external systems, 
because private addresses cannot be used in the internet. It is also possible that the internet service provider take care 
of all no29.bahnstrasse.donn.de-name translation requests from external systems. In any case external systems can 
only reach the home network gateway and not the respective devices 1 ; 1 A, 1 B within the home network, as it is shown 
5 in figure 4. 

[0052] Figure 4 shows the system shown in figure 3 and the procedure of an internet device to access the storage 
media device 1 B of the home network. The internet device first sends a query to the DNS server of the home network: 
"Who is storage.no29.bahnstrasse.bonn.de?" and gets in a second step the IP address of the external interface of the 
controller 2 as an answer from the DNS server, here: "192.109.206.33", in other words, not the IP address of the stor- 

10 age media device 1 B is given to the device requesting the IP address of "storage.no29.bahnstrasse.bonn.de", but only 
the IP address of the external interface 2b of the controller 2. In this case a warning can be displayed on the display and 
input device 8 that somebody is accessing the home network from the internet. If necessary an authentication and/or 
authorization procedure is included during the session setup. Whoever sends a request through the internet can now 
access the storage media device 1 B via the controller 2 in a third step, but not directly. 

15 [0053] As a work around for this problem, according to the present invention, a new universal resource identifier (URI) 
convention is defined that supports HTTP access from the internet to home network devices 1 ; 1 A, 1B through the 
home network gateway, i. e. the controller 2. 

[0054] The complete domain name is obviously necessary to access a remote ISP sub-domain from an internet site, 
however, within the home network environment it would be difficult to use such a long name for each device. To avoid 

20 this, as in current IP networks, client devices within the home network could assume a default domain. In the above 
described example an appropriate default domain name would be "no29.bahnstrasse.bonn.de". 
[0055] By mapping a name to multiple IP addresses also resource management with DNS is possible. As home net- 
works have various devices which can only support one user or one task, it is possible that the network may have sev- 
eral of such devices. In this case, an intelligent name server is able to map a generic device name, e. g. 

25 "dvbtuner.no29.bonn.de", to the IP address of a free device. To enable addressing of specific devices, unique names 
can also be assigned. 

[0056] In the following, the controlling of the home network devices 1; 1A, 1B shown before with HTTP will be 
explained with reference to figures 5 to 10. 

[0057] In most conventional HTTP applications servers are addressed with a universal resource locator (URL) that 
30 consists of a server domain name, i. e. the fully qualified domain name, followed by a path which refers to an HTML 
document on that server. With this approach the main menu of e. g. a DVB tuner would be called "http://dvb- 
tuner.no29.bahnstrasse.bonn.de/index.htmr. With this URL, browsers inside the home network would first look up the 
IP address for "dvbtuner.no29.bahnstrasse.bonn.de". The DNS server would then reply with the internal IP address and 
consequently the browser would send the HTTP get command: "GET/i ndex.html" to this IP address. Browsers in inter- 
35 net would also lookup this domain, but they would receive the gateway's external IP address as it is shown in Figure 4. 
[0058] To enable the access from internet systems through the home net gateway in the controller 2, it is secured that 

• the gateway will be able to receive HTTP requests and can forward these requests to home network devices 1 ; 1 A, 
1B, 

40 • furthermore, the gateway can find the destination device in the home network, since the domain name is copied to 
the path, e. g.: 

"http://dvbtuner.no29.bahnsstrasse.bonn.de/dvbtuner.no29.bahnstrasse.bonn.de/index.html". 

[0059] With this new URL convention, according to the present invention, the audio video devices initialize their HTTP 
45 servers 3 as it is shown in Figure 5. For a remote tuner device 1 A according to the invention, a main HTML document 
is stored in the memory of the HTTP server 3. This main HTML document could for example be: 

<A HREF="httpy/tuner.no29.bahnstrasse.bonn.de/tuner.no29.bahnstrasse.bonn.de/next.cgi"iiext<\A> 
<A HREF="http://tuner.no29.bahnstrasse.bo 
so (A HREF= ,, http7/storage.no29.bahnstrasse.bonn.de/storage.no29.bahnstrasse.bonn.de"lstorage(\A> 
(A HREF=* "rittp-y/camera.no29.bahnstras 

[0060] The main HTML document in the memory of the HTTP server 3 included in the remote storage media device 
1 B according to the present invention could for example look like: 

55 

<A HREF="http^/storage.no29.bahnstrasse.bonn.de/storage.no29.bahnstrasse.bonn.de/next.cgi"hext<\A) 
<A HREF="lTttp://storage.no29.bahnstrasse.to^ 

(A HREF="http7/tuner.no29.bahnstrasse.bonn.de/tuner.no29.bahnstrasse.bonn.de"iuner<\A> 



8 



i 

EP 0 940 959 A1 

<A HREF="http://camera.no29.bahnstrasse.bonn.de^ 

[0061] It is possible for each HTTP server to find the local domain name by performing an inverse DNS lookup. This 
means, every HTTP server can determine its domain name by asking the local DNS server to translate its IP address, 
s Alternately, the name server can use a preferrably standardized generic local domain name, e. g. "home net", if the 
home network has never been connected to the internet. 
[0062] Every server will compile HTML documents which describe: 

Its current services; a g. in case of a tuner this refers to the broadcast signal, which it receives as its input; to 
10 describe such signals the tuner will convert MPEG data and/or associated DVB SI (Digital Video Broadcasting 
Service Information) data to HTML data; e. g. in case of a storage device in recording mode this refers to the input 
signals such as audio/video data on isochronous channels; besides the textual description of the services as 
shown in Figure 5, preferrably also the audio video data will be presented in the HTML menu. To support moving 
pictures, the commands "server push" or "client pull" can be used to update the picture regurlarly; 
is • service selection operations, such as "next" service and previous, i. e. "back", service if this exists; each server 
device will associate appropriate scripts or programms with such entries; 

furthermore, each server can provide links to other devices on the home network; to determine the latter, the server 
could poll other devices, e. g. at port 80, as this is the default IP port for HTTP traffic, and make an associated entry 
if that device responds; alternatively each server could snoop (= capture IP packets) to determine which other serv- 
20 ers are active. 

[0063] As it is shown in figures 5 and 6, after initialization of the HTTP servers 1 ; 1 A, 1 B and the controller 2, the dis- 
play and input device 8 connected to the controller 2 displays a message "Which device would you like to access?" to 
a user. If a user types in or utters a command, e. g. "storage", as it is shown in Figure 6, the controller 2 has first to rec- 

25 ognize this command. If a successful recognition has been conducted, a second step of the controller is to perform a 
DNS lookup for the input command, here "storage", in the default domain, here "no29.bahnstrasse...". In a third step, 
the DNS server replies with the internal IP address, e. g. 192.168.0.3 for the remote storage media device 1B. The 
browser included in the controller 2 then sends in a fourth step the HTTP command "GETr to the internal IP address 
of the wanted device, here to the address 192.168.0.3. 

30 [0064] Figure 7 shows the response of the HTTP server with the address 1 92. 1 68.0.3, here the remote storage media 
device 1 B, to this universal resource locator not sent in the new URL convention. In a fifth step the server, i. e. the stor- 
age media device 1 B, notices this old style URL and consequently sends a server redirect response, i. e. 

try "http^/storage. no.29.bahnstrasse.bonn.de/storage. no.29.bahnstrasse.bonn.de" instead I 
[0065] The browser complies with the redirect response and sends in a sixth step the new URL "GET storage. 

35 no29.bahnstrasse.bonn.de". During such an automatic conversion and during the waiting time caused by the asynchro- 
nous connection the display and input device 8 connected to the controller 2 shows the message: "Fetching menu...". 
[0066] In figure 8 it is shown that in a seventh step the server 3 of the storage media device 1 B sends an HTML page 
"index.html". The Browser receives this HTML data and presents it as graphical user interface (GUI) to the user on the 
display and input device 8, which displays e. g. the name of the remote storage media device 1B "STORAGE" and the 

40 available commands, e. g. next, back, tuner/camera and a picture taken by a not shown camera which is the selected 
input device of the remote storage media device 1 B at the moment. 

[0067] With the first menu from the selected remote storage media device 1 B, the user notices in this case that this 
device is currently connected to a camera. As the user might wish to record from the tuner instead of the camera, he 
requests the next service, as it is shown in figure 9, with uttering the word "next". In an eigth step the controller 2 rec- 
45 ognizes this command, the Browser finds in the following step 9 the "next" anchor and sends the HTTP command 
"GET/storage.no29.bahnstrasse.bonn.de/next.cgi" to the IP address 192.168.0.3 of the remote storage media device 
1 B. In the tenth step the HTTP server 3 of the remote storage media device 1 B receives this command and executes 
the script "next.cgi". Therefore, the storage media device 1 B selects a new isochronous channel and presents a new 
menu. 

so [0068] In figure 1 0 it is shown that in a eleventh step the controller 2 receives the updated menu from the remote stor- 
age media device 1 B and presents it to the user on the display and input device 8 connected thereto. The new menu 
now includes the data received on the isochronous channel that connects the remote tuner device 1 A with the remote 
storage media device 1 B, in this case the picture of CNN. 

[0069] As the user has put the remote storage media device 1 B in the desired state, he can now switch to the remote 
55 tuner device 1 A with the "tuner" command, to select a desired channel. 

[0070] To make these commands less ambiguous and to indicate e. g. that the last line of the menu will connect the 
Browser with a different audio/video device more details and graphics are required and can be included on the respec- 
tive HTML page. 
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[0071] Again the browser will try to find an anchor, associated with the command "tuner". It will then follow the HREF 
field in that anchor. Consequently it will perform a DNS lookup for "tuner.no29.bahnstrasse.bonn.de" and send the 
HTTP command "GET/tuner.no29.bahnstrasse.bonn.de" to the appropriate IP address. The latter will return the menu 
associated with that path, which will include information on currently selected services. Also this menu has "next" and 
"back" entries, but these will perform operations that are different from the next and back operations of the storage 
media device 1B. For example, the tuner's "next" operation may change the tuner's frequency while the tuner output 
remains on the same isochronous channel number. 

[00721 According to another embodiment of the present invention it is also possible that the menus of all or certain 
selected remote devices connected to the controller 2 are displayed at the same time on the display input device 8 con- 
nected to the controller 2. 

[0073] To enable an easier set-up of isochronous channels, Figure 1 1 shows the principles of an extended network 
initialization, the unsolicited audio video data broadcasting, that is explained in the following again using the IEEE 1394 
network system. 

[0074] In conventional IEEE 1394 applications, like e. g. a digital video cassette application, the controller interacts 
with the user and then, depending on the user's input, controls both source and target devices at almost the same time. 
Therefore, to large extend, conventional controllers are able to conceal the network topology from the user. One of the 
disadvantages of this approach is that, in the worst case, a newly purchased source or target device will have limited or 
no influence in the graphical user interface of the controller. Consequently, the upgrade would appear to have limited or 
no effect. According to this invention, device manufacturers can develop devices with their own graphical user interface 
that allows the user to control each device directly. The intend is that the user orchestrates interaction between devices 
by successively controlling source and destination devices as described in the examples above. 
[0075] To improve the user friendliness it is desireable to avoid constraining the order of controlling the remote 
devices. In other words, the user should have the freedom to choose which source/remote device to control first. For 
this purpose, according to the invention each device which is capable of sending data on isochronous channels can 
start broadcasting such data in the preferred data format soon after start up. From a technical point of view such broad- 
casting can be called "unsolicited" as unlike in conventional networks, no direct or indirect user command is required to 
initiate isochronous data transfer. These devices can also continue broadcasting after basic connections have been 
established. If necessary, to avoid wasting bandwidth, video data with a high degree of temporal and spatial redundancy 
can be used for this purpose. In case of e. g. MPEG2 transport streams, such video data can be compressed efficiently 
to very low bit rates. If such a signal is not available at the input of the broadcasting device, in other words, if there is no 
bit rate signal available which can be forwarded to the IEEE 1394 isochronous channel, it could be generated with hard- 
ware or software in the device. Preferrably, this initial isochronous data will also provide information for the user to help 
understand the type and state of the device. 

[0076] Existing IEEE 1 394 devices, i. e. legacy devices, do not support the capability to generate such a low bit rate 
stream internally. However, according to the invention, new devices can instruct these legacy devices to start broadcast- 
ing data, albeit at conventional bit rates, on isochronous channels soon after start up. In case of tuners, this effectively 
means forwarding cable or satelite bit streams to the home network. Storage media devices with tuners, e. g. VCR's, 
could also forward broadcasting services to avoid mechanical operations. In case where it is not desireable that legacy 
devices behave this way, e. g. because of bandwidth, power consumption or other limitations, the system can inform the 
user that these devices should be programmed first. 

Claims 

1 . A method for establishing connections between remote devices (1 ; 1 A, 1 B, 1 C), characterized by controlling said 
remote devices (1 ; 1 A, 1 B, 1 C) independently by using a hypertext transfer protocol. 

2. The method according to claim 1 , characterized in that said remote devices (1 ; 1 A, 1 B, 1 C) are controlled via a 
control device (2), which controls said remote devices (1 ; 1 A. 1 B, 1 C) by using a hypertext transfer protocol. 

3. The method according to claim 2, characterized by remotely controlling said control device (2) by using a hyper- 
text transfer protocol. 

4. The method according to claim 2, characterized by directly controlling said control device (2) via a user interface 
(8). 

5. The method according to anyone of claims 2 to 4, characterized in that said control device (2) respectively down- 
loads a user interface from each of said remote devices (1 ; 1 A, 1 B, 1 C) which is to be connected with said connec- 
tion and offers said user interfaces or a modified user interface based on said user interfaces to a user who wishes 
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to control said remote devices (1 ; 1 A, 1 B, 1 C). 

6. The method according to claim 4 or 5, characterized In that a graphical user interface is used as said user inter- 
face. 

5 

7. The method according to anyone of claims 1 to 6, characterized in that said connection between said remote 
devices (1 ; 1 A, 1 B, 1 C) is a guaranteed bandwitdh connection. 

8. The method according to anyone of claims 1 to 7, characterized in that said connection between said remote 
w devices (1; 1A, 1B, 1C) is established via an IEEE 1394 bus system (5). 

9. The method according to anyone of claims 2 to 8, characterized in that a fully qualified domain name is assigned 
to each of said remote devices (1; 1A, 1B, 1C) in an initialization step that respectively consists of a name of a 
respective remote device (1 ; 1 A, 1 B, 1 C) prepended to a name of said controller (2). 

15 

10. The method according to anyone of claims 2 to 9, characterised in that said name of said controller is a domain 
name which is assigned by an Internet access provider. 

1 1 . The method according to claim 9 or 1 0, characterized in that said fully qualified domain name is copied to the path 
20 of each hypertext transfer protocol command of each universal resource locator used to control said remote 

devices (1; 1A, 1B, 1C). 

12. The method according to anyone of claims 1 to 11, characterized in that a hyperlink to all connected remote 
devices (1 ; 1 A, 1B, 1C) is assigned to each of said remote devices (1; 1A, 1B, 1C) in an initialization step. 

25 

13. A remote device (1 ; 1 A, 1 B, 1 C) for establishing a connection to other remote devices (1 ; 1 A, 1 B, 1C), character- 
ized by a control interface (3) via which said remote device (1 ; 1 A, 1 B, 1 C) is controllable using a hypertext transfer 
protocol to establish said connection. 

30 14. The remote device (1 ; 1 A, 1 B, 1 C) according to claim 1 3, characterized in that said control interface (3) is a hyper- 
text transfer protocol server and stores a user interface to be downloaded by said remote device (1 ; 1 A. 1 B, 1 C) to 
a control device (2). 

15. The remote device (1 ; 1 A,. 1 B, 1C) according to claim 14, characterized in that said user interface is a graphical 
35 user interface. 

1 6. The remote device (1 ; 1 A, 1 B, 1 C) according to anyone of claims 1 3 to 1 5, characterized in that said connection 
Is a guaranteed bandwitdh connection. 

40 17. The remote device (1 ; 1 A, 1 B, 1C) according to anyone of claims 13 to 16, characterized by a data interface (4) 
via which said connection is established. 

18. The remote device (1 ; 1 A, 1 B, 1 C) according to claim 1 7, characterized in that said remote device (1 ; 1 A, 1 B, 1 C) 
starts forwarding or generating at least one service via said data interface (4) automatically after being switched-on. 

45 

1 9. The remote device (1 ; 1 A, 1 B, 1 C) according to claim 1 7 or 1 8, characterized in that said data interface (4) is an 
IEEE 1394 interface for isochronous connections. 

20. The remote device (1; 1A, 1B, 1C) according to anyone of claims 14 to 19, characterized in that it includes a 
so domain name server that assigns a fully qualified domain name to each of said remote devices (1 ; 1 A, 1 B. 1 C) in 

an automatic initialization step that respectively consists of a name of a respective remote device (1; 1A, 1 B, 1C) 
prepended to a name of said control device (2) which could be assigned by an Internet access provider. 

21. The remote device (1 ; 1 A, 1 B, 1C) according to anyone of claims 13 to 20, characterized in that it includes a unit 
55 to poll all other connected remote devices (1 ; 1 A, 1 B, 1C) to generate a hyperlink to all other connected remote 

devices (1; 1A, 1B, 1C). 

22. The remote device (1 ; 1 A, 1 B, 1 C) according to anyone of claims 1 3 to 20, characterized in that it includes a unit 
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to snoop the traffic on the connections to and inbetween the connected remote devices (1 ; 1 A, 1 B, 1 C) to generate 
a hyperlink to all other connected remote devices (1 ; 1 A, 1 B, 1 C). 

23. A control device (2) with a first interface (2a) for controlling remote devices (1 ; 1 A, 1 B, 1C) by use of a hypertext 
s transfer protocol characterized by a second Interface (2b) for controlling said control device (2) using a hypertext 

transfer protocol for establishing a connection between at least two of said remote devices (1 ; 1 A, 1B, 1C). 

24. The control device (2) according to claim 23, characterized by means for downloading at least one user interface 
from said remote devices (1 ; 1 A, 1 B, 1 C) connected thereto via said first interlace (2a) and for offering at least one 

10 of said user interfaces at a time to a user so as to establish a connection between at least two of said remote 
devices (1; 1A, 1B. 1C). 

25. The control device (2) according to claim 23 or 24, characterized in that said connection is a guaranteed band- 
witdh connection. 

15 26. The control device (2) according to anyone of claims 23 to 25, characterized in that said user interface is a graph- 
ical user interface. 

27. The control device (2) according to anyone of claims 23 to 26, characterized In that it is integrated into a standard 
20 personal computer. 

28. The control device (2) according to anyone of claims 23 to 27, characterized in that it includes a domain name 
server that assigns a fully qualified domain name to each of said remote devices (1 ; 1 A, 1 B, 1C) in an initialization 
step that respectively consists of a name of a respective remote device (1; 1A, 1B, 1C) prepended to a name of 

25 said control device (2) which could be assigned by an Internet access provider. 
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Fig. 3 
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Fig. 4 
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External interface 

IP address: 192.109.206.33 
Netmask: 255.255.255.0 

Default router 192.109.206.1 
DNS server 192.168.0.1 



ONS SERVER responsible for 
no29.bahnstrasse.bonn.de. 
ONS database content: 



sub- answer for answer for 
domain internal devices external devices 



tuner 192.1680.2 
storage 192.160.0.3 
contr. 192.1G0.0.1 
etc ^ 



192.109 206.33 
192.109.206.33 
192.109.206.33 



Which 

device would 
you like to 
access? 
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Fig. 6 



■A 



Tuner 



^Processor & HTTP server, 
main HTML document in RAM: 

<A HREF='Tittp://tunef. no29.bahnstrassc.bonn.de/ 

tijrw.rK329,barinstrasse.bonn.de/hext.cgi*>next<\A> 
<A HREF=Ttttp7Auner.nq29.bannstrasse.bonn.de/ 

tuner.rw29.bahnstrasse.bonn.de/back.c0 ff >back<\A> 
<A HREF«TTttp7/storaQe.rio29.bahnstrasse.bonn.de/ 

$torage.no29bahnstrasse.borin.de">storagB<\A> 
<A HREF=Tittp7/camera.no29.bahnstrasse.bonn.de/ 

camera.no29.bahrtstrasse.bonn.de">camefa<\A> 



Storage Media 



r 



ma 



liProcessor & HTTP server 
main HTML document in RAM: 



4- 



<A H R E F="http://storage .no29. bahnstrasse bonn.de/ 

storage. no29.bahnstrasse.borm.demext.cgr>next<va : • 
<A HREF="http://storage .no29.bahnstrasse.bonn.de/ , 

storage.no29.bahnstrasse.bonn.de>back.cgi">back<\ i > 
<A HREF=7mp7Auner.no29.bahnstrasse.bonn.de/ 

tunerno29.bahnstrasse.bonn.de">tuner<\A> 
<AHREF» s http7/camera.no29.bahnstrasse.bonn.de/ 

camera.no29.bahnstrasse.bonn.de*>camera<\A> 



Controller & gateway 



Controler's IP properties: 

Internal interface 

IP address: 192.168.0.1 
Netmask: 255.255.255.0 

External interface 

IP address: 192.109.206.33 
Netmask: 255.255.255.0 

Defau* router 192.109.206.1 
DNS server: 192.168.0.1 



v.. 



Browser sends HTTP "GET r 
command to 192.168.0.3 
3. DNS replies with internal IP address 
2. Controller does DNS lookup for storage 
in default domain (no29.bahnstrasse..) 
1 . Controller recognizes command 




•storage" 



1 



Which 

device would 
you tike to 
access? 
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XL 



Fig. 7 



Tuner 



Storage Media 



jiProcessor & HTTP server, 
main HTML document in RAM: 



XL 



<A HREF=TTttp:/ytuner.no29.bahnstrasse.bonn.de/ 

tuner.no29.bahnstrass«.bonn.deMext.cgr>next<\A> 
<A HREF»'Mp:/Auner. no29.bahnstrasse.bonn.de/ 

tuner.no29.bahnstrasse.borin.deybacfc.cgi~>back<VA> 
<A HREF=Ttftp://storage.no29.bahrtstrasse.borin.de/ 

storage.no29.bahnstrasse.bonn.de">storago<\A> 
<A HREF="httpy/camera.no29.bahnstrasse.bonn.de/ 

camera.no29.bahnstrasse.bonn.de">camera<\A> 



____J__. 



^Processor & HTTP server 
main HTML document in RAM: 



r 



<A HREF="http://st orage.no29.bahrtstrasse.bonn.de/ 

storage.no29.bahnstrasse.bonn.de/hext.cgi ">n#xt<v4 
<AHREF=Tittp://storage.no29.bahnstrasse.bonn.de/ 

storege.no29.bahnstrasse.bonn.deyback.cgi">back<\rt> 
<A HREF*Ttrtp:/rtuner.no29 .bahnstrasse.bonn.de/ 

tuner.no29.bahnstrasse.bonn.de # >tur»r<\A> 
<A HREF=^ttp://carnera.no29.bahnstrasse.bonn.de/ 

camera.no29.bahnstrasse.bonn.de'>camera<\A> 



Controller's IP properties: 

InternaJ interface 

IP address: 192.168.0.1 
Netmask: 255.255.255.0 

External interface 

IP address: 192.109.206.33 
Netmask: 255.255.255.0 

Oefautt router 192.109.206.1 
DNS server 192.168.0.1 



• 



Controller & gateway 




Server notices old style URL consequently 
sends server redirect response i.e. 
try 'http://storage.no29.bahnstrasse.bonn.de/ 
sto^age.no29.bahnstrasse.bonn.de , in stead! 



6. browser sends 

GET storage.no29.bannstrasse.bonn.de 




Fetching j j 
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Fig. 8 



Tuner 



^Processor & HTTP server, 
main HTML document in RAM: 



<A HREF=s"http:/Auner.no29.bahnstrasse.bonn.de/ 

tuner.na29-bahnstrasse.bonn.de>hext.cgi">next<\A> 
<AHREF=Trttp:/Auner.no29.barmstrasse.bonn.de/ 

tuner.no29.bahnstrasse.bonn.de>badtcgi">back<\A>i 
<A HREF="http^/storaoe.no29.bahnstrasse.bonn.de/ ; 

storage.no29.bahnstrasse.bonn.de">slorage<\A> 
<A HREF- , rtttpV/camera.no29.bahnstrasse.bonn.dey 

camera.no29.bahnstrasse.bonn.de">camera<\A> 




fiProcessor & HTTP server 
main HTML document in RAM: 

<A HREF=7rtp://storage.rio29. bahnstrasse.bonn.de/ 

storage.no29 .batoistrasse.bonn.de/hext.cgi">next<v3|: ■ 
<A HREF=*http://storage.no29.bahnstrasse.bonn.de/ 

storage.no29.bahnstrasse.bonn.deA3acK-cgi">back<\J4> 
<A HR E F="http 7Auner.no29.bahnstrasse.bonn. de/ 

tuner.no29.bahnstrasse.bonn.de">tuner<\A> 
<A HREF="http7/camera.no29.bahnstrasse.bonn.de/ 

camera.no29.bahnstrasse.bonn.de">camera<\A> 
t 



Controller & gateway 



Controller's IP properties: 

Internal interface 

IP address: 192.168.0.1 
Netmaslc 255.255.255.0 

External interface 

IP address: 192.109.206.33 
Netmask: 255.255.255.0 

Default router 192.109.206.1 
DNS server: 192.168.0.1 



7. Server sends index-html. The browser receives 
this HTML data and presents it as GUI to user 



• 



STORAGE. 
Next 



0 0 



Tuner/Camera 
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Fig. 9 



XL 



Tuner 



^Processor & HTTP server, 
main HTML document in RAM: 

<A HREF="http:/Auner.no29.bahnstrass€.bonn.de/ 

tuner.no29.bahnstrasse.bonn.deyhext.cgi">next<\A> 
<A HREF=TTttp:/Auner.no29.bahnstrasse. bonn.de/ 

tuncf.no29.bahnstrasse.bonn.de/back. cgj">back<NA> 
<A HREF-"httpy/storage.no29.bahnstrasse.bonn.de/ ' 

stonige.no29.bannstra$se.bonn.de">storage<\A> 
<A HREF»T^y/camera.no29.bahnstrasse.bonade/ 

canwajio29.bahnstrasse.bonn.de^camera<\A> 




^.Processor & HTTP server 
main HTML document in RAM: 

<AHREF=Tittp^/storage.no29.bahnstrasse.bonn.de/ 

storaoe.no29.bahnstrasse.bonn.de/next.coi'>next<\4 
<A HREF="http7/storage .no29.bahnstrasse.bonn.de/ 

storage rK529.bahnstrasse.bonn.deyback.cgi">back<\4> 
<A HREFs-http7/luner.no29.bahnstrasse.bonn.de/ 

tuner. no29.bahnstrasse.bonn.de'>tunar<\A> 
<A H REF=Tittp7/ca mera.no29.bahnstrasse.bonn.de/ 

camera.no29.bahnstrasse.bonn.de'>camera<\A> 



X 



Controller's IP properties: 
Internal interface 

IP address: 192.166.0.1 
NetmasJc 255.255.255.0 

External interface 

IP address: 192.109.206.33 
NetmasJc: 255.255.255.0 

Default router: 192.109.206.1 
DNS server 192.166.0.1 



Controller & gateway 



10. HTTP server receives command And 
executes script "next.cgi" / 

9. Browser finds "next" anchor, / 
and sends HTTP command / 
"GET /storage. no29. bah nstrasse.bonn.qJe/ 
nextcgi" to 192.168.0.3^ 

8. Controller recognizes command 



'next' 



./ 



i . 



STORAGE: 
Next 
Back 



0 0 



Tuner/Camera 
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Fig. 10 



Tuner 



XL 



^Processor & HTTP server, 
main HTML document tn RAM: 

<A HREF=*http7/Tuner.no29.bahnstrasse.bonn.de/ ! 

tuner.rw29.bahr«trasse.bonn.de/next.cgi">next<\A> j 
<A HREF=TittpjyUjner.no29. bartnstrasse.bonn.de/ | 

tunef.no29.bahnstrasse.bonn.de/back,c^">bacK<\A>j 
<A HREF=*rjttpV/stonage.no29.bahnstrasse.bonn.de/ j 

stofage.no29.bannstrasse.bonn.de">storage<\A> 
<A HREF=Ttftp://carnera.no29.bahnstrasse.bonn.de/ 

camera.no29.bahnstrasse.bonnde , >cam«ra<W> 



Storage Media 



J 



r 



uP roc ess or & HTTP server 
main HTML document in RAM: 



<A HREF=*http://storage.no29.bahnstrasse.bonn.de/ 

storaq^.no29.bahnstrasse.bonn.de/hext.cgi , '>next<\Af 
<AHREF="rttp://slorage.no29.bahnstra5se.bonn.de/ 

storage.no29.bahnstrasse.bonn.de/back.cof >back<\^ 
<A HREF="http://tuner.no29.bahnstrasse.bonn.de/ 

tuner.no29.bahnstrasse.bonn.de'*>tiiner<\A> 
<A HREF=TTttp://camera.no29.bahnstrasse.bonn.de/ 

camera.no29.bahnstrasse.bonn.de">camera<\A> 



Controller's IP properties: 

Internal interface 

IP address: 192.168.0.1 
Neimasic 255.255.255.0 

External interface 

IP address: 192.109.206.33 
Netmask: 255.255.255.0 

Default router 192.109.206.1 
DNS server 192.168.0.1 



ftuner" 



2 ControHer & gateway 




'X 



11. Controller receives updated menu from 
storage device, and presents it to user. 



12. User instructs browser to 
switch to tuner 



STORAGE: 

Next j 

Back CNN 

| Tuner/Camera 
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Fig. 11 



Unsoidtsd A V data 



Isochronous connections 



Tuner 



^Processor 



t. 



1A 



Controlier 



Please 
x *mt a 
moment... 



[ Storage Media 



luProcessor 



1B 



Asynchronous 
connections 




Display & input device 
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Fig, 12 



Tuner 



Storage Media 



Camera 



Antenna 




^ 1 



- 1 




« 






r 


^2 




ControHer . 

Input and > 

Output device. 

etc. 



Physical 
connections 
in home net 
supporting 
both isochronous 
and asynchronous 
data traffic. 
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PRIOR ART 



Fig. 13 



{- 



Tuner 



r J 



1A 



.1 



^Processor 



1 



Isochronous connections 



Storage Media 





* 


L 


1 1 



^Processor 




r 



Asynchronous 



Display & input device 
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PRIOR ART 



Fig. 14 



Source Device: 
Radio Transmitter 



Target Device: 
Radio. URL = 

http7AA^.chiltonxom/scripts/radio/R8-receiver 




Device Control 
with HTTP 



CONTROLLER 
Web Browser 



102 



-» Audio data 

Device control or device status information 



Asynchronous 
connection; 
Point-to-point 
connection for 
AV data and for 
device 

control protocols. 



101 



103 
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Fig. 15 



PRIOR ART 



Source device; 
www.agavista.digital.com. 



Ortgjnai 



f 



T — 

www.lycos.cam www.excite.com 



1 HTTP server 


F 1 


i 

J 




Process. 



104 



2 or more 
available 

sources. Accessible 
with HTTP. 



"Target device" 
www.yahoo.com. 



Pro 



I HTTP server 



HTTP 



CONTROLLER 
Web Browser 



102 



105 



Asynchronous 
connections; 
for device control 
and data retrieval 
with HTTP. 



-s> Possible routes for data requested by user. 
Device control or device status information 
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